Coverage increased (+0.01%) to 97.157% when pulling 677f5b8 on tomap:master into 00151a1 on hexojs:master.

Hi @tomap. It seems like a good idea. Where does the updated variable show up in the site?

My use case is in feed plugin where the update date of a post makes no sense in my case, where I would want them to not use the file dates, but instead use the date, when no update is set.

https://github.com/hexojs/hexo-generator-feed/blob/master/atom.xml#L24

However, after giving it some thought, I think it is more an option of feed to introduce or a new post property, otherwise, it will create a change of behavior

@tomap Should we ask hexo core team their thoughts and see if anyone wants to talk more about this? I cannot yet understand what depends on these dates but it seems like a good idea you had.

Yes, we should, especially given the breaking change possibility

IMHO, this will change the purpose of the updated date field. I know some plugins use this field to set the updated date for the posts. Why not we modify the hexo-generator-feed to handle the date correctly, instead of changing the hexo itself?

Agreed. I'll do a PR there

Hi, I thougth a bit more about it and it is important to have this change inside hexo.
Here is why:
1/ if I do it at the plugin level, I'll have two variables available:

• Date (date of publication)
• Updated, which will be either the "true" updated date (from the front-matter), and a meaningless date (mtime) but with no way for me to kwno which is which

2/ If I do it at hexo level (with an option, for backward compatibility)

• Date (date of publication)
• Updated, which will be either the "true" updated date (from the front-matter), or the date of publication (if no updated date is available)

So I'm reopening this PR, and will amend it soon to include the new option for backward compatility (backward compatible behavior if false or unset)

Using file mtime as updated affect not only hexo-generator-feed but also any theme using variable post/page.updated.

For example, my hexo-theme-suka supports a feature which based on post/page.updated:

In my case, I believe it is a b better option to use date as updated when no updated is given in front-matter.

I prefer not dropping mtime, it's quite useful, although I personally prefer to manually set the post.updated. I'm ok with introducing new option (as shown in your latest commit.

Would updated: (in similar format as date:) in front matter resolve the issue you mentioned? Kinda similar approach as #3612.

@curbengh indeed, mentionning updated in my posts would solve the situation, but I don't want to have to mention them to fix the issue.
I want the default to work in my case
That is why I'm introducing a new option

These two seem to be conflicting:

Updated, which will be either the "true" updated date (from the front-matter), or the date of publication (if no updated date is available)
// Use post date for updated date instead of file modification date when front-matter provides no date

shouldn't it be "...when front-matter provides no updated date"?

These two seem to be conflicting:

Updated, which will be either the "true" updated date (from the front-matter), or the date of publication (if no updated date is available)
// Use post date for updated date instead of file modification date when front-matter provides no date

shouldn't it be "...when front-matter provides no updated date"?

I fixed that. Thank you

Thanks. I'll test it in the meantime.

"lib/plugins/processor/asset.js" only affects page, similar lines also need to be added to "post.js".

Note to theme dev, If a theme currently display updated date, it needs to add another condition:

if (post.updated && post.updated.toString() !== post.date.toString()) { %>

Edit: my comment below has better option.

Or we could introduce an easier property that would leave the updated property empty in case it is not set in front matter?

The condition I mentioned is for compatibility when use_date_for_updated is enabled. Now I think about it, the following condition works better,

<% if (post.updated && !config.use_date_for_updated) { %>

Edit: Just realized the above condition will not display post.updated if use_date_for_updated is enabled. My previous comment still works.

Or we could introduce an easier property that would leave the updated property empty in case it is not set in front matter?

I would prefer that option, so if (post.updated) works better.

mtime_updated perhaps?

@tomap

Or we could introduce an easier property that would leave the updated property empty in case it is not set in front matter?

Are you going to implement that option in this PR or later? Otherwise, this is good to go.

I'm not going to change this PR.